Switch to GH Actions #1607
Switch to GH Actions #1607
Conversation
nhooyr
force-pushed
the
ci
branch
5 times, most recently
from
a774de6 to
432f081
Compare
nhooyr
force-pushed
the
ci
branch
19 times, most recently
from
001309c to
f528fb4
Compare
nhooyr
force-pushed
the
ci
branch
3 times, most recently
from
2dd076c to
630d418
Compare
The architecture specific jobs pull it in and then build releases. Much faster!
nhooyr
force-pushed
the
ci
branch
2 times, most recently
from
2ea8a72 to
3800ae4
Compare
Much better test now as well.
|
I merged for testing automating publishing then docker image/npm. The GitHub Actions API requires the workflow file be in master for the API to work properly. Please still review @code-asher |
|
Nvm I was wrong, got the API working not related to merge but still review @code-asher |
| - run: ./ci/steps/release-static.sh | ||
| env: | ||
| # Otherwise we get rate limited when fetching the ripgrep binary. | ||
| GITHUB_TOKEN: ${{ secrets.github_token }} |
There was a problem hiding this comment.
Should we set this for the other jobs as well?
There was a problem hiding this comment.
Only macOS for some reason needs it. The others never fail.
| as artifacts on Github Actions. | ||
| 1. Create a new draft release with the built release packages. | ||
| 1. Run some basic sanity tests on one of the released packages. | ||
| 1. Publish. |
There was a problem hiding this comment.
I think we should mention to include the VS Code version in the release notes, see #1501 (comment). Including a changelog is of course obvious but maybe we should mention that as well (which at some point we should probably start generating automatically).
There was a problem hiding this comment.
You got it.
I'd be in favour of a manual changelog, commits can get verbose. I'd rather we summarize the big changes ourselves.
| 1. Run some basic sanity tests on one of the released packages. | ||
| 1. Publish. | ||
| 1. Download the built npm package and publish it. | ||
| 1. Place the debian releases into `./release-packages` and then push the docker |
There was a problem hiding this comment.
I don't know if this is better or worse but my strat was to pull the versioned Docker image, tag it latest, then push it back up.
There was a problem hiding this comment.
Actually I see in your other PR the image is pushed after a release is created so I suppose we could also just push latest? Since at that point we'd have verified the release is good to go.
| @@ -68,15 +85,13 @@ This directory contains the container for CI. | |||
|
|
|||
| ## steps | |||
|
|
|||
| This directory contains a few scripts used in CI. Just helps avoid clobbering .travis.yml. | |||
| This directory contains a few scripts used in CI. | |||
| Just helps avoid clobbering .travis.yml. | |||
There was a problem hiding this comment.
I suppose we don't have a .travis.yml anymore, maybe we can make this generic with CI configuration file(s) or something.
|
|
||
| - [./steps/test.sh](./steps/test.sh) | ||
| - Runs `yarn ci` after ensuring VS Code is patched | ||
| - [./steps/release.sh](./steps/release.sh) | ||
| - Runs the full release process | ||
| - Generates the npm package at `./release` | ||
| - [./steps/static-release.sh](./steps/static-release.sh) |
There was a problem hiding this comment.
Looks like this is release-static.sh now.
| - [./build/test-release.sh](./build/test-static-release.sh) | ||
| - Ensures code-server in the `./release-static` directory runs | ||
| - [./build/build-static-pkgs.sh](./build/build-static-pkgs.sh) (`yarn pkg`) | ||
| - Uses [nfpm](https://github.com/goreleaser/nfpm) to generate .deb and .rpm from a static release | ||
| - [./build/build-packages.sh](./build/build-static-pkgs.sh) (`yarn package`) |
There was a problem hiding this comment.
The names on the left don't match the right. Looks like on the first one the right is correct and on the second the left is correct.
Fixing. |
Travis ARM is very unreliable :(